What?

• Add a useServerSideTests hook which wraps a React Context provider.
• Provide a proof-of-concept for how it might be used (wrapping a page at a high level, so that the context is available to all sub-components.
• Add a sketch of how this context could be mocked in a standardised way in Storybook.

Why?

Sometimes we need to access server-side test switches in DCR.

The options currently available:

• Prop drilling from the top level component down to the component which needs the switch data.
• If the component is wrapped in an <Island> then it can access the window.guardian config on the client side, which includes server-side test information.

Our component tree is very deep in some places (e.g. elements of a fronts card could easily be 10 levels down from the root component which has direct access to the switch data). This makes prop drilling more time-consuming and error-prone. Generally we have an established preference for prop drilling in DCR but for temporary tests the cost of adding and then removing multiple levels of prop drilling seems disproportionately high.

Alternatives to the status quo:

• Singleton pattern?
• A more radical re-think of how we implement server-side tests in DCR.
• React Context (or some other similar 'global' store) <-- The approach explored in this RFC.

The React Context approach avoids prop drilling and uses an idiomatic React pattern to do so.

Precedents

• ADR deciding not to use Context
• But we are currently using it for a similar purpose in AMP: ContentABTest.tsx
• See also Kent C Dodd's post on this pattern.

Pitfalls

'Magic' creep

As mentioned above, the accepted pattern in DCR is to favour prop drilling in part because it's more explicit, and relies less on the kind of 'magic' which can make a codebase hard to reason about.

In this RFC I am not suggesting that we should give up this pattern in general. Using the wrapper and custom hook allows us to limit the footprint of Context to a specific use-case, and also allows the Context Provider to be read-only. In this way I don't think it sets a precedent of reaching for Context as a catch-all shortcut.

Fragments and Storybook

If we put the ServerSideTestProvider at the top level of each of the main rendering components (as I have in ArticlePage.tsx in this branch) then most components should have the context if and when they need it. But this doesn't apply to Storybook stories, or any other place where we might render components outside these main routes.

As things stand, the useServerSideTests hook will throw a runtime error if it's used outside of the ServerSideTestProvider. We could rewrite it to catch the error (or not throw it in the first place) but it's probably good to have it fail loudly.

I've added a decorator function which could be used in Storybook to mock the context provider. Because it's a decorator, it can be applied to individual stories or to whole sets of stories for a component, which should reduce boilerplate.

That said, we might still face an inverse prop-drilling issue, whereby adding a context hook to any child component requires at least one of its parent components to contain the context provider. (e.g. adding a test to cards will break all the container stories.) That would be quite annoying. One way around this might be to create a global Storybook decorator which yields 'control' for any test name that's queried. Generally speaking we'll want our storybook to reflect the 'control' versions of components anyway, and there's nothing to stop us from opting in to the 'variant' for particular stories using something like the mocking function I've sketched here.

Nevertheless, the fact that tooling doesn't seem to be able to easily identify whether the relevant context will be present feels like a bit of a negative.

Tooling

Throwing a runtime error if the hook is used outside of the Provider scope should mean that issues are caught before they're deployed. But it would be nice if it could fail earlier (i.e. by provoking linter or compiler errors). I don't know if there's a good option for doing this.